Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Checklists

Working checklists for architecture review, procurement and design review. They are written to be testable: each item is answerable with evidence or it is not answerable at all.

Use them at an architecture review board, during vendor evaluation, and at design review. Adapt them; a checklist nobody owns is a document.

National digital health architecture​

  • The health problems being solved are named, with outcome measures
  • A capability model exists, mapped to current systems, showing gaps and overlaps
  • Priority workflows are documented, with organisational handoffs marked
  • "Patient", "encounter", "facility" and "provider" have agreed definitions
  • The authoritative identifier for each is decided and published
  • A facility registry exists, is governed, and is used by more than one system
  • Terminology bindings are decided for the top three coded fields
  • The exchange pattern (centralised / federated / hybrid) is decided and recorded as an ADR
  • The legal basis for data sharing is established, in writing
  • The consent model is decided, including break-glass
  • Architecture principles are published and testable at review
  • An architecture review body exists with authority over procurement
  • Shared services have a funding model beyond the current programme
  • Named owners exist for each shared service
  • Degraded-mode behaviour is defined for every system on the clinical critical path
  • A maturity assessment has been done with evidence, and the two lowest dimensions are in the investment plan

FHIR implementation​

  • The FHIR version is stated (R4 / R4B / R5) and consistent across participants
  • A named implementation guide governs the exchange — not "FHIR"
  • The IG derives from an existing one (IPS, IPA, a national IG) rather than base FHIR
  • Extensions are justified individually; the registry and existing IGs were searched first
  • Terminology binding strengths are deliberate, not all example
  • mustSupport has a written definition in this IG
  • A CapabilityStatement is published and accurate
  • Examples are provided and they validate
  • Validation runs in CI against the profiles
  • Search parameters needed by consumers are supported and documented
  • Versioning policy for the IG is stated, including breaking changes
  • A sandbox with synthetic data exists for implementers
  • Conformance testing is required before production connection
  • Identifiers use registered, permanent namespace URIs

Health information exchange​

  • Legal basis established before build
  • Client, facility and health worker registries operating
  • Exchange pattern decided and recorded
  • At least one consumer exists who will actually read the data
  • Terminology mapped for the data in scope
  • Interoperability layer with authentication, routing, audit and replay
  • Machine identity per participant per environment; no shared credentials
  • Error contract defined, with a triage queue and a named human owner
  • Participant onboarding and conformance process documented
  • Availability target set, with edge behaviour when unmet
  • Store-and-forward at every point-of-service system
  • Audit retention policy set; audit access controlled
  • Business-level monitoring, not only technical (link rates, queue age, last-message-received per participant)
  • Participation agreement and trust framework with enforcement
  • Exit process for a participant, including what happens to its data

EMR selection and architecture​

  • Stores both local and shared patient identifiers
  • Uses facility and health worker registry identifiers
  • Emits data against the national implementation guide, demonstrated by test
  • Terminology is configurable, not hard-coded
  • APIs are documented and carry no additional integration licence fee
  • Data is extractable in a standard format, with the exit cost in the contract
  • Audit logging meets the required standard
  • Functions during a central-service outage, with a defined degraded mode
  • Queues outbound exchange with retry; never silently drops
  • Records provenance: source system and asserting clinician
  • Supports amendment and retraction without losing history
  • Role and attribute-based access control adequate to the setting
  • Vendor commits to patching and vulnerability disclosure
  • Ten-year total cost stated, including hosting, support and upgrades

Security​

  • Threat model documented per major component
  • TLS 1.2+ everywhere, including internal traffic
  • Encryption at rest, with keys in a key management service
  • Key rotation and recovery procedures documented and tested
  • No secrets in source control; history scanned; found secrets rotated
  • MFA for remote access to clinical data
  • Shared-workstation authentication designed so attribution survives
  • Network segmented; medical devices isolated
  • Certificate inventory with expiry monitoring and automated renewal
  • Dependency, container, IaC and secret scanning in CI
  • SBOM generated per build and retained
  • Audit records separate from application logs, tamper-resistant
  • Health-specific detections built (VIP access, no-care-relationship access, volume anomalies, repeated break-glass)
  • Incident response plan rehearsed, including clinical continuity
  • Backups encrypted, with one immutable copy; restores tested
  • RTO and RPO set per system by clinical consequence
  • Penetration test performed and findings tracked to closure

Privacy​

  • Legal basis identified per data flow
  • Consent model decided and implemented as a service
  • Consent withdrawal works, and its limits are explained honestly to patients
  • Consent history reconstructable for any past access
  • Purpose of use asserted, recorded and reviewable
  • Break-glass available, logged, notified and reviewed
  • Data minimisation applied: narrow queries, id-only notifications, scoped exports
  • Retention periods defined and enforced
  • De-identification method documented with a re-identification risk assessment
  • No personal health data in telemetry; leakage tested for
  • Bulk export requires a documented purpose, recipient and retention period
  • Patients can find out who accessed their record
  • Privacy impact assessment completed and reviewed

Terminology​

  • Inventory of coded fields and what each is coded with today
  • Code systems selected per field, with rationale
  • Value sets published, versioned and dated
  • Binding strengths deliberate
  • Intensional value sets have dated expansions where they affect reporting
  • ConceptMap equivalence assertions are accurate, not uniformly equivalent
  • Terminology served by a service, not hard-coded in applications
  • Change request, review and release process documented, with an owner
  • Consumers notified of releases
  • Old versions retained as long as data coded against them
  • Terminology releases treated as high-risk changes, with clinical review
  • Analytics cohorts defined by the same value sets used at data capture
  • Offline snapshot available for edge systems

Master patient index​

  • Matching strategy decided and recorded, with the reason
  • Thresholds set conservatively; false positives treated as the worse error
  • Human review queue exists, is staffed, and is worked
  • Review queue depth and age monitored and reported
  • Duplicate rate measured and published by source system
  • Search-before-create implemented at every registration point
  • Data capture quality addressed before algorithm tuning
  • Temporary identifiers issuable, with a path to permanence
  • Merge propagates to downstream systems
  • Unmerge is possible and has been tested
  • Retired identifiers continue to resolve
  • Adversarial cases tested: twins, common names, single names, transliteration, name changes, estimated birth dates
  • Matching evaluated against real local data, not synthetic

API​

  • Authentication per client, per environment
  • Authorisation enforced at the resource, not only at the token endpoint
  • aud, iss, exp validated on every token
  • PKCE required; no password grant
  • Rate limiting and result-size caps
  • Pagination on every collection endpoint
  • Versioning strategy, with a deprecation policy and notice period
  • Documented error contract with actionable codes
  • Idempotency for all writes
  • Timeouts and circuit breakers on outbound calls
  • Every access audited, permit and deny
  • Sandbox with synthetic data
  • Machine-readable specification published

Cloud architecture​

  • Data residency requirements established in writing from legal counsel
  • Region choice verified as lawful for identifiable data
  • Availability tier per system, agreed with clinical leadership
  • Multi-AZ or equivalent for high-tier systems
  • Disaster recovery region and a rehearsed failover
  • Backups outside the primary account or tenancy
  • Cost model over ten years, with egress costs included
  • Exit path from managed services assessed, with cost
  • Infrastructure as code; nothing configured only by hand
  • Least-privilege IAM, reviewed periodically
  • Monitoring, alerting and logging in place before go-live
  • Operational team identified and staffed for the chosen complexity

AI in health​

  • Named clinical owner
  • Intended use documented, with explicit out-of-scope uses
  • Regulatory classification established for this jurisdiction
  • Legal basis for the data used in development
  • Evaluated on local data, reported by subgroup
  • Failure modes analysed, including plausible-but-wrong outputs
  • Human-in-the-loop, with override always available and recorded
  • Outputs written to the record labelled as model-derived, with version in provenance
  • Every inference audited: model version, inputs, output, viewer, action
  • Monitoring for input drift, output drift, subgroup performance and override rate
  • Defined thresholds and an explicit stopping rule, with an owner authorised to stop it
  • Scheduled review date
  • Incident process for suspected model harm
  • AI embedded in procured products inventoried and governed the same way

Offline-first​

  • Device holds a complete record of record for its scope
  • Local identifiers are UUIDs, reconciled centrally without blocking work
  • Clinical data modelled as append-only events
  • Conflict strategies defined per data type; nothing discarded silently
  • Sync is chunked, resumable and idempotent
  • Sync status visible to the user, including last successful sync
  • Reference data versioned on-device, with size budget and update path
  • Rule version recorded with each assessment
  • Local storage encrypted; offline user authentication with bounded cache
  • Remote wipe procedure documented
  • Device lifecycle planned, including 20–30% annual turnover
  • Tested: multi-day disconnection, interrupted sync, wrong clock, full storage, app upgrade with unsynced data pending

Disaster recovery​

  • RTO and RPO defined per system by clinical consequence
  • Backups: 3-2-1 plus one immutable or air-gapped copy
  • Backups include configuration and terminology, not only the database
  • Restores tested on a schedule, to a clean environment, and timed
  • Failover procedure documented and rehearsed
  • Degraded-mode clinical procedures documented and practised
  • Paper fallback forms available, with a reconciliation process
  • Contact tree current, including out-of-hours and clinical leadership
  • Criteria pre-agreed for disconnecting from the national exchange
  • Dependencies mapped, including third parties
  • Post-incident review process with findings tracked to closure

Using these​

  1. Bring the relevant checklist to the review; do not summarise it from memory
  2. Require evidence, not assertion — "yes" is not an answer, a test result or a document is
  3. Record exceptions with an expiry date and an owner
  4. Feed recurring failures back into the checklist

See governance and templates.

Last updated on